The Project Management Institute focuses on the trade-offs among the project triad of scope, time and cost in order to frame its approach to project management. Our experience indicates that there is a fourth variable in any project management decision to be considered - quality.

As practicing project managers, and as individuals who have been asked to turn around projects in trouble, we have faced the reality of this fourth variable time and time again. A project manager can always save time and dollars by pushing quality issues into the future. In software development, this often leads to releasing software that contains "known bugs". Anyone who uses commercial software has been subjected to the results of such decisions.

Seven Key Project Management Ideas

1. Every one involved with any project, or any phase of a project, must know its anticipated sunrise (start) and sunset (estimated completion).
2. A project that is initiated without an explicit risk assessment is a project where project team members and project clients are unaware of the risks that they are taking.
3. A project without project metrics is an unmanaged project.
4. Large projects need time-boxed phases or sub-projects.
5. The amount of planning detail required for a project is a direct function of the aggregate risk of the project.
6. The main purpose of a project plan is to educate the team members and the project clients about who must do what with whom when. It is a work integration, accountability definition, and relationship management tool.
7. Projects where the project team members do not know the deliverables expected by project clients and their personal part in creating them are not projects.

An Eighth Overriding Project Reality

There can be only one top level project manager and one top level project client for a project.

1. Individuals who share final project management accountability need to be able to become one integrated decision making personality - which human beings do not know how to do. Similarly, individuals who share the top level client need to be able to become one integrated decision making personality.
2. Both the top level project manager and the top level project client can have others who act in the same role but are subordinate to them for the decision making purposes.

Project often have steering committees. Project management training (see the Project Management Institute web site for information) includes guidance for project managers on dealing with the members of such steering committees. However, little guidance exists for members of project steering committees. If you are in this role, you may find it useful to download the following guide for project steering committee members.

"Handbook for New Members of Automation Project Steering Committees"

Pilot or prototype projects are very different from structured automation projects. The few pages in the link below describes some of the main differences that both project managers of such projects, and members of their steering committees, need to be aware of.

"Managing Pilot Projects"

Time-boxing has a second benefit. It limits the amount of risk taken at any one point in time on high risk projects. After several years of experience with explicit risk analysis for all projects, we know that such analysis is a necessary part of all project initiation. Our experience with this approach started with software development. However, we quickly learned to modify the approach to organizational change and other types of projects.

Essentially, the technique applies a template of risk assessment questions to a project plan. Such templates involves scoring the project on the project on the following types of factors.

• Size - the bigger the project (time and dollars), the greater the risk.
• Newness - the newer the technologies and the processes used, first in the industry, and then to the people impacted by the project, the greater the risk.
• Players - the more varied the players involved in, or impacted by the projects, the greater the risk.
• Organizational Boundaries - the more internal and external organizational boundaries that have to be crossed during project activity, the greater the risk.
• Experience - the less the experience of the project players with the technologies, the processes, the organizations, and the fewer the number of established preexisting proven relationships between them, the greater the project risk.

The scoring is done very quickly (days). It is best if both project leaders and project clients participate in the scoring. It can done in either survey or workshop mode. The first is faster. The second, when led by an experienced facilitator, creates a greater degree of understanding and consensus among key project individuals. The results lead to action.

For each area where project risk is beyond a low or medium level, explicit risk management and mitigation activities must be part of the project plan. For any project phase where the aggregate risk level is above a low or medium level, regular risk review dialogue must occur among the project manager and the senior project clients.

Project Metrics

A project which does not keep track of its key input and output metrics is an unmanaged project. Even low or medium risk projects go off track with regular reporting of basic metrics.

This is not the same as project accounting. Like all accounting, project accounting must track project costs accurately to the penny. It is simply a subset of fiscal accounting and must face the same rigorous accounting standards that normal accounting meets. That takes time. It often takes more time than a project has available if team members are to take effective corrective action.

Project metrics therefore must meet a somewhat different standard. Project measurements must correctly predict the trend of a project's consumption of resources and the size and quality of its output.

Accurate estimates are often as effective at doing this as "every transaction" accounting methods. Estimates are usually cheaper and faster to collect and to trend.

Project managers on all projects need to establish (or use already existing) processes that allow them:

• to collect,
• to trend into the future - to project end,
• to regularly report at intervals which do not exceed 20% to 25% of the estimated project duration,

the following basic metrics. Everyone on the project team needs access to these metrics so that they know where the project stands. All project clients need access to the same metrics.

Input metrics:

• Project team hours expended to date.
• Estimated committed project dollar expenditures to date (if the only major project resource is talent, that is, there are no major equipment or facilities expenditures, then project teams hours is a good substitute for this metric)

Output metrics:

• Some reasonable measure(s) of specific project output - one that makes sense given the nature of the project (some examples follow)
  • lines of software code in production,
  • number or percentage of software modules or components delivered,
  • number of engineering designs, plans or drawings completed,
  • number of people converted to or trained in new processes,
    
    
• Generic project output measures
  • actual and number of or percentage of planned project deliverables completed,
  • number or percentage of project activities completed,
  • project gateways or key targets met on target or late by ... ...
  • ... ...
    
    
• Project client satisfaction with progress to date -

  Even an informal measure collected in conversation by the project manager with key project clients and reported as a simple average ranging from 1 (not satisfied at all) to 10 (totally satisfied) is better than "hidden dissatisfaction".
  

Time-boxing

In the past years, we have had the opportunity to work with software project management approaches that address the scope, time, cost and quality trade-offs by consciously limiting the scope of any one phase of a larger project. Called time-boxing, this approach essentially says do what you can do in 30, 60, 90 or 120 days. Focus on delivering something that has some utility to the project clients. Let them experience these results. See if they are prepared to fund the next phase of the project based on this experience. Time-boxing replicates the basic principle of limiting the available resources which has proven so successful in managing pilot projects in many other disciplines.